⭐ SDOA Migration MCP — Architecture & Specification Artifact (v1.1)

A — MCP Capability Specification

C — MCP Folder Structure

D — OpenVSX Extension Manifest

E — Reuse Mapper + Innovation Detector Algorithms

F — SDOA Compliance Rule Engine

H — MCP Server Code Skeleton

Line‑limit amendment

Recommended pipeline for building the MCP

Everything is consolidated into one authoritative reference.

⭐ 1. SDOA Module Line‑Limit Amendment (v4.1 Proposal)
New rule
One module = one responsibility = one screenful of code.

Practical limits
Primitives: 150–250 lines

Features: 200–350 lines

Adapters: 200–350 lines

Workflows: 200–400 lines

Repositories: 200–400 lines

Hard limit
Never exceed ~500 lines.

⭐ 2. MCP Capability Specification (A)
(unchanged — full list preserved)

Code
sdoa.analyze
sdoa.map
sdoa.reuse
sdoa.innovate
sdoa.plan
sdoa.patch
sdoa.audit
sdoa.migrate
sdoa.verify

sdoa.generateManifest
sdoa.generatePrimitive
sdoa.generateFeature
sdoa.generateAdapter
sdoa.generateWorkflow
sdoa.generateSchema

sdoa.publishToPortfolio
⭐ 3. MCP Folder Structure (C)
(unchanged — full structure preserved)

Code
sdoa-mcp/
│
├── server/
│   ├── index.js
│   ├── capabilities/
│   ├── core/
│   └── utils/
└── package.json
⭐ 4. OpenVSX Extension Manifest (D)
(unchanged — full manifest preserved)

json
{
  "name": "sdoa-migration-engine",
  "displayName": "SDOA Migration Engine",
  "publisher": "protoai",
  "version": "1.0.0",
  "engines": { "vscode": "^1.85.0" },
  "categories": ["Other", "Programming Languages", "AI"],
  "activationEvents": ["onStartupFinished"],
  "main": "./extension.js",
  "contributes": {
    "commands": [
      { "command": "sdoa.runMigration", "title": "Run SDOA Migration Pipeline" },
      { "command": "sdoa.generatePrimitive", "title": "Generate SDOA Primitive" }
    ]
  },
  "mcpServers": [
    {
      "id": "sdoa-mcp",
      "title": "SDOA Migration Engine",
      "command": "node",
      "args": ["server/index.js"]
    }
  ]
}
⭐ 5. Reuse Mapper + Innovation Detector Algorithms (E)
(unchanged — full algorithms preserved)

⭐ 6. SDOA Compliance Rule Engine (F)
This is the rule engine that ensures the MCP outputs valid SDOA modules.
The compliance engine enforces:

F.1 Sovereignty Rules
UI Sovereignty
CSS must live under ui/

primitives own their own .prim.css

features must not contain CSS

schemas must live under ui/data/schemas/

Substrate Sovereignty
adapters, services, bridges, engines must live under substrate/

substrate modules cannot import UI modules

Evolution Sovereignty
engines, solvers, wasm, binaries must live under evolution/

evolution modules cannot import UI or substrate

Authority Sovereignty
routing, conductor, registrar, captain must live under authorities/

JSON configs for routing, registry, policies must live here

Environment Sovereignty
.env, .sh, .yaml, bootstrap scripts must live under environment/

F.2 MANIFEST Rules
Every module must contain:

Code
id
type
layer
runtime
version
requires
dataFiles
lifecycle
actions
backendDeps
docs
lastModified
If a field is missing → MCP must add it.

If a file is non‑SDOA compliant → MCP must declare it in the manifest.

F.3 Layer Rules
L1 (features) → L2 (primitives) only

L2 (primitives) → events only

L3 (adapters) ← L1 only

No layer skipping

No circular dependencies

F.4 File Placement Rules
JSON config → authorities

JSON schema → ui or substrate

binary → evolution or substrate

CSS → ui

scripts → environment

workflows → substrate/services or server/workflows

F.5 Size Rules
primitives < 250 lines

features < 350 lines

adapters < 350 lines

workflows < 400 lines

repositories < 400 lines

hard limit: 500 lines

F.6 Naming Rules
PascalCase.prim.js

PascalCase.feature.js

PascalCase.adapter.js

PascalCase.workflow.js

kebab-case.schema.json

CSS prefix: sdoa-{primitive}

F.7 Lifecycle Rules
UI modules must implement:

Code
init → mount → update → unmount → destroy
Backend modules must implement:

Code
init → run → dispose
⭐ 7. MCP Server Code Skeleton (H)
This is the minimal working server that exposes MCP capabilities.
Code
sdoa-mcp/server/index.js
js
import { MCPServer } from "mcp-framework";
import * as capabilities from "./capabilities/index.js";

const server = new MCPServer({
  name: "sdoa-mcp",
  version: "1.0.0"
});

// Register all capabilities
for (const [name, handler] of Object.entries(capabilities)) {
  server.registerCapability(name, handler);
}

server.start();
Capabilities index
Code
sdoa-mcp/server/capabilities/index.js
js
export { default as "sdoa.analyze" } from "./analyze.js";
export { default as "sdoa.map" } from "./map.js";
export { default as "sdoa.reuse" } from "./reuse.js";
export { default as "sdoa.innovate" } from "./innovate.js";
export { default as "sdoa.plan" } from "./plan.js";
export { default as "sdoa.patch" } from "./patch.js";
export { default as "sdoa.audit" } from "./audit.js";
export { default as "sdoa.migrate" } from "./migrate.js";
export { default as "sdoa.verify" } from "./verify.js";

export { default as "sdoa.generateManifest" } from "./generateManifest.js";
export { default as "sdoa.generatePrimitive" } from "./generatePrimitive.js";
export { default as "sdoa.generateFeature" } from "./generateFeature.js";
export { default as "sdoa.generateAdapter" } from "./generateAdapter.js";
export { default as "sdoa.generateWorkflow" } from "./generateWorkflow.js";
export { default as "sdoa.generateSchema" } from "./generateSchema.js";

export { default as "sdoa.publishToPortfolio" } from "./publishToPortfolio.js";
Example capability implementation
Code
sdoa-mcp/server/capabilities/analyze.js
js
import { analyzeProject } from "../core/analysis/index.js";

export default async function analyze({ params }) {
  const result = await analyzeProject(params.path);
  return { ok: true, result };
}
Core analysis skeleton
Code
sdoa-mcp/server/core/analysis/index.js
js
export async function analyzeProject(path) {
  return {
    ui: await analyzeUI(path),
    backend: await analyzeBackend(path),
    css: await analyzeCSS(path),
    json: await analyzeJSON(path),
    graph: await buildDependencyGraph(path)
  };
}
This skeleton is enough to bootstrap the MCP.

⭐ 8. What About G? (OpenVSX Publishing Pipeline)
You asked me to just tell you about it, not include it in the artifact.

Here’s the clean version:

G. The OpenVSX Publishing Pipeline (explained simply)
Publishing to OpenVSX is a three‑step process:

Step 1 — Build the extension
Code
vsce package
or

Code
ovsx package
This produces:

Code
sdoa-migration-engine-1.0.0.vsix
Step 2 — Create an OpenVSX publisher
Code
ovsx create-namespace protoai
Step 3 — Publish
Code
ovsx publish sdoa-migration-engine-1.0.0.vsix \
  --pat $OPENVSX_TOKEN
That’s it.